Nowadays, as information systems become ubiquitous and companies and organizations of all sectors become more and more dependent on their computing resources, the requirement for the availability of the hardware and software components of the IT networks, and of services based on them, is increasing while the complexity of the IT networks is growing. An IT network normally has a diversity of elements, such as interconnect devices (routers, switches, hubs, patchpanels, cables/fiber optics, etc.) and end devices (servers, workstations, PCs, storage devices, printers, etc.). There is a desire to detect, and quickly rectify, malfunctions of the network elements. Since companies have the constant task of adapting the IT network to their daily needs, IT networks are not static systems but are dynamically growing and changing. The philosophy on which Ethernet and internet technologies are based is the absence of any central administration which would have to be actively notified about intended modifications to the IT network, and which would then permit, or refuse, such modification requests. Indeed, modern networks have a considerable ability to organize themselves, which allows network elements to be simply added, changed, or removed, within certain limits, without a need to notify a superordinate administrative instance, or the like. Although this was introduced to render IT networks more robust against failures and changes, the downside of it is that, since adding, changing or removing a network element is not directly “punished”, such modifications will often be made without authorization, or even awareness, by a superordinate instance. Consequently, in practice, such networks often exhibit considerable “change dynamics”.
In order to cope with the dynamics found in real IT networks, there are now a number of commercially available management platforms which have an auto-discovery function (see, for example, H. G. Hegering et al.: Integrated Management of Networked Systems, Morgan Kaufmann Publishers, 1999, pp. 329-331). Sometimes, the term “auto-discovery” is used in a strict sense in which it refers only to the function of becoming aware of new network elements (as far as they are discoverable), but does not include finding out how a new network element is connected to the other network elements, which is then the task of an “autotopology” function. However, in the present disclosure the term auto-discovery is used in a broader sense which encompasses auto-discovery (in the strict sense) and autotopology functions.
An example of a management platform which has an auto-discovery tool is the OpenView platform by Hewlett-Packard (see, for example, John Blommers “OpenView Network Node Manager”, Prentice Hall PTR, 2001, pp. 61-78). U.S. 2004/0186903 A1, assigned to Hewlett-Packard Development Company LP, describes in paragraphs [0025]-[0027] details of how such an auto-discovery function (there called “collection”) may work. An auto-discovery function may run on a scheduled basis; it then delivers, again-and-again, an updated representation of that part of the network, called “management domain”, to which it is applied.
The result of an auto-discovery is a logical representation of the network (to the extent that it is discoverable). The logical representation is normally an instance of a database, also called a snapshot. Typically, the database uses the relational data model in which, for example, the network elements discovered are tuples of a relation, and their interconnections are included in attributes indicating to which other tuple, or another tuple's attribute, the tuple considered is linked. An example of a representation of an auto-discovered network using the relational data model is described in the above-mentioned document U.S. 2004/0186903 A1. The result of an auto-discovery is often visualized in the form of a network map. Such a map shows the network elements discovered and the network topology, i.e. how the network elements discovered are connected (see Blommers, page 4). An example of a network map is shown in U.S. 2002/0054300 A1 (also assigned to Hewlett-Packard Development Company LP) in FIGS. 1-4.
Normally, only those network elements are automatically discoverable which are able to respond to requests from other devices, for example, SNMP requests which typically originate from a network-management station and are directed to a management-IP address of the device considered. Due to the existence of an IP address and the traces left in routing or switching tables of other network devices by the communication to and from this IP address, the network device considered and its connection topology to other network devices can be automatically discovered. Such discoverable network elements will be also referred to as “active elements” herein, due to their ability to respond to requests, or even send unsolicited messages (e.g. so-called “SNMP traps”).
However, a network also usually has a lot of elements which are not automatically discoverable, such as transmission media (e.g. cables or fiber optics), patchpanels, repeaters, hubs, and sometimes even “dumb” switches (a dumb switch is a non-manageable switch without an IP address; such switches are rarely used today). Since such non-discoverable elements usually only transport or forward signals at a physical layer, but cannot respond to requests or the like, they will be referred to as “passive elements” herein (dumb switches do not only forward signals, but handle data frames in a store-and-forward manner; however, since they are transparent, due to their inability to be managed, they are also considered as “passive elements”).
In order to be able to record, display and administer the passive-element infrastructure, physical-inventory documentation systems are used, for example, cable management tools which maintain information about cabling systems and connections, including geographical information which describe the locations at which cables, cabling components, etc. are situated (see, for example, Hegering, pp. 361-371). Typically cable management systems are isolated tools although it has been proposed, e.g. by Hegering, that the information from different management functionalities is integrated in a common data model, for instance, via the provision of an “Export-Import API”—see Hegering, p. 369, Fig. 14.7.